home *** CD-ROM | disk | FTP | other *** search
/ Aminet 31 / Aminet 31 (1999)(Schatztruhe)[!][Jun 1999].iso / Aminet / dev / basic / UDP_Chat.lha / UDPChat / Lag problems in Net games next >
Text File  |  1999-03-29  |  22KB  |  457 lines
  1. On 11-Apr-98, Paul Burkey wrote:
  2. >Hi Dave,
  3.  
  4. >> Now that's all fine, I can do most of the TCP/IP stuff pretty
  5. >> easily, but I have some other problems. Does anyone know of the best
  6. >way
  7. >> to do 8 seperate players playing on the same game over the internet.
  8. >Like
  9. >> how would you linkup 8 players...all to one player, or all in a
  10. chain.
  11.  
  12. >With more than 4 players I'd avoid the chain idea. That is unless you
  13. >can deal with large amounts of lag and you don't need to be fully
  14. >synchronised. The 1 server many clients idea is the safest and easiest
  15. >system to deal with but ALWAYS the best way.
  16.  
  17.    First check out Paul's netpage:
  18.   <http://www.sneech.demon.co.uk/netlink.html>  
  19.  
  20.    It's got some links to pages with the problems you're likely to come
  21. up against. I've been researching this for the last 6 or so months (with
  22. some help from Paul), because I want to put multiplayer internet support
  23. into a similar type of game as yours- a fast reaction arcade game. The
  24. big problem as far as I can see is the lag you get from when one
  25. computer sends a move, and the other machine receives it. This is worse
  26. on a 2D game because you'll see if something's a few pixels out- on a 3D
  27. game you'll never really notice anything is out, unless the lag is
  28. terrible. You have to do everything to cut down the lag time
  29.  
  30. >> it depends on how much data I'm gonna have to send to every player.
  31. >> And that's the second problem, do I just send co-ordinates of
  32. >> every player, and say ever players bullets, and any objects
  33. >> they pick up, or do I send just the players action, and work out the
  34. >> outcome of that action and then reply with a message to say that it
  35. >worked
  36. >> okay.
  37.  
  38. >As always it's not easy to give any firm directions with this kind of
  39. >stuff. You may have good reasons why you need to keep things
  40. >synchronised
  41. >or you may have a design that can cope with large amounts of lag. It
  42. >depends on the gameplay really. I'd probably suggest using the I/O
  43. >method where instead of sending coordinates or players, bullets
  44. >and whatever else. You just send the players inputs. So if player 1
  45. >moves forwards you send this. If he doesn't move anywhere then you
  46. >don't send anything.
  47.  
  48.    Yes, I think this is the only way you could have it work for lots of
  49. players- otherwise you'd physically run out of bandwidth (you wouldn't
  50. be able to get enough information through the modem in a given time).
  51. Instead of sending out each new pixel position of an object, you just
  52. send out differences in speed, acceleration and direction with a
  53. time-stamp. As all machines are time-synced at the start you can then
  54. adjust the Avatar (copy of your player etc on another machine) to the
  55. exact position the original is on-screen (using simple physics), because
  56. you know what speed and direction it was traveling at a certain point in
  57. time. Your characters actually are in sync more than the position method
  58. which would always be behind by whatever the lag was. This is how
  59. Quake/XWing etc do it. 
  60.   So if a monsta is traveling down a corridor, you can ignore it until
  61. it goes down a different angled corridor, then you send this info out to
  62. the other machines. You just have to have one machine only, responsible
  63. for each object onscreen- so I was thinking of using the Server to say
  64. which machine is responsible for which monsta etc (even though I'm using
  65. peer-to-peer, I've got a Server to log in to), and other objects like
  66. bombs, doors, etc could be controlled this way as well. This solves your
  67. problem about having two players in one space, as only one machine makes
  68. the decisions for each object. You might get visual glitches like
  69. shooting a player and it misses them when it should have hit, because
  70. the actual player was really a few pixels off, but if the lag times can
  71. be kept down this shouldn't be much of a problem.
  72.  
  73.    A point raised on one of the web pages, was the problem that could be
  74. caused by lag. Say for example, a monsta has AI that makes it chase a
  75. player on line-of-sight. If a player changes direction just before an
  76. intersection say, and a monsta is in line-of-sight of that intersection
  77. eg:
  78.  
  79. -------------+-+--------------
  80.             P->                           P- player
  81. -------------+ +--------------
  82.              | |
  83.              | |
  84. -------------+ +--------------
  85.               M->                         M- monsta
  86. -------------+-+--------------
  87.  
  88.  
  89.   If the lag to one machine is greater than another, you could get the
  90. situation of the monsta going in two different directions on the two
  91. machines. On the machine with the faster connection the Avatar has
  92. turned back (as the human player has), so the monsta carries on along
  93. the way it was going; on the machine with the slightly slower connection
  94. the Avatar goes a few pixels into the corridor before turning back, and
  95. the monsta sees it and changes direction and chases it down the
  96. corridor. Once the monsta changes course on one machine, the courses of
  97. the two monstas will continue to diverge :-/  (sort of like that old (I
  98. think it was H.G Wells') sci-fi story about the guy who goes back in
  99. time and accidentally kills a butterfly :)
  100.   If you have the one machine only making decisions for an object, it
  101. solves this problem. 
  102.  
  103. >> Like if 4 players each tried to enter the same square, and only 1
  104. >> could...which one would it be, and how would I tell all the others
  105. >which
  106. >> one it was. I hope that hasn't confused everyone...cos it's confused
  107. >me.
  108.  
  109. >This is where the 'one server many clients' idea can make life very
  110. >easy. The following is just a rough plan, I'm making most of it up
  111. >as I go along so feel free to pick the ideas appart until we can
  112. >agree on a solution. Also lets understand that this idea would work
  113. >for some gams and not for others...
  114.  
  115. >Lets imagine you have 20 players. Each player would have a unique
  116. >number eg 1,2,3..20. Now imagine that each player has to send
  117. >commands to the server and wait for the command to arive back before
  118. >the command can be executed. A command may be something like 'shoot',
  119. >'move forwards', 'move backwards' or whatever. Any commands player
  120. >1 sends to the server will be mirrored to all other players as well
  121. >as himself. Now lets imagine that the server is setup so that it
  122. >will take incomming commands for 1/10 of a second and then send
  123. >them all out. If no commands are taken then the server will send a
  124. >'no commands' message to everyone. The game would be setup to
  125. >gather these commands and sort them into order. So all player 1
  126. >commands would be executed first, then player 2 and so on. A better
  127. >solution would be for the server to attach a timestamp to each
  128. >command as it arives. Then a batch of commands are sent out and
  129. >these can then be sorted into the same order as thy arived on
  130. >the server.
  131.  
  132. >Some extra error checking should be used in this example but theres
  133. >no need to go into too much detail here.
  134.  
  135. >To get back to your question.. Each player would move towards
  136. >this same square at the same time. So the 'move to square'
  137. >command is sent to the server and then the server sends these
  138. >commands to the players. All players will attempt to execute
  139. >the commands in the same order so player 1 will be first and
  140. >then player 2. Player 2 can't move into the square because
  141. >player 1 beat him to it.
  142.  
  143.    This is ok as long as it runs fast enough for your game- for an
  144. arcade type game I think it might run too slow (as you have to send the
  145. message to the Server and then back to the Client (which could double
  146. lag times). I'm using Peer-to-Peer (every machine sends its messages to
  147. all machines), which by-passes the Server. 
  148.    In Quake, I think they have a max of 8 players peer-to-peer, and up
  149. to 16 going through a dedicated Server (as in Paul's way, but only to
  150. pass messages on, not to do any logic). But these Servers are rather
  151. powerful with a fast direct net connections.
  152.  
  153.    This is all theory at the moment as I haven't had time to put the
  154. code into a small test game to see what works :-/
  155.  
  156.    Also am using UDP instead of TCP which is much faster but has no
  157. error checking. I've done a little chat program using UDP which checks
  158. wether packets have arrived at their target or not, and has a basic
  159. log-in Server- but all message